We previously checked for containsUnexpandedParameterPack in CSEs by observing the property
in the converted arguments of the CSE. This may not work if the argument is an expanded
type-alias that contains a pack-expansion (see added test).

Check the as-written arguments when determining containsUnexpandedParameterPack and isInstantiationDependent.

(cherry picked from commit c83d9be)

Do not attempt to check a dependent requires clause in a function constraint
(may be triggered by, for example, DiagnoseUseOfDecl).

(cherry picked from commit a424ef9)

'this' context was missing in instantiation of member requires clause.

(cherry picked from commit 60f5da7)

Attributes are permitted on friend definitions, but we only checked for
a proper function body, not for the =default / =delete cases.

(cherry picked from commit 5ae6554)

A constrained function with an auto return type would have it's definition
instantiated in order to deduce the auto return type before the constraints
are checked.

Move the constraints check after the return type deduction.

(cherry picked from commit 980517b)

(cherry picked from commit 1db66e7)

This reverts commit 41f4dfd.

It broke standalone libc++ builds, which now try to use libc++abi from the wrong directory, instead of system instance.

…ks, support substitution into SubstNonTypeTemplateParmExpr

We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts.
Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into
template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator.
We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP
with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent).

(cherry picked from commit ba1f3db)

…ectly

isDeclarationSpecifiers did not handle some cases of placeholder-type-specifiers with
type-constraints, causing parsing bugs in abbreviated constructor templates.

Add comprehensive handling of type-constraints to isDeclarationSpecifier.

(cherry picked from commit b7ce85a)

types are needed to compute the return type of a defaulted operator<=>.

This raises the question of what to do if return type deduction fails.
The standard doesn't say, and implementations vary, so for now reject
that case eagerly to keep our options open.

(cherry picked from commit 42d4a55)

overrides the final overrider in a different base class.

(cherry picked from commit aade5fb)

…e name

(cherry picked from commit f00ab18)

During the review of D73007 Aaron Puchert mentioned
`warn_for_range_variable_always_copy` shouldn't be part of -Wall since
some coding styles require `for(const auto &bar : bars)`. This warning
would cause false positives for these users. Based on Aaron's proposal
refactored the warnings:

* -Wrange-loop-construct warns about possibly unintended constructor
  calls. This is part of -Wall. It contains
  * warn_for_range_copy: loop variable A of type B creates a copy from
    type C
  * warn_for_range_const_reference_copy: loop variable A is initialized
    with a value of a different type resulting in a copy
* -Wrange-loop-bind-reference warns about misleading use of reference
  types. This is not part of -Wall. It contains
  * warn_for_range_variable_always_copy: loop variable A is always a copy
    because the range of type B does not return a reference

Differential Revision: https://reviews.llvm.org/D73434

(cherry picked from commit c03349e)

…figuration time check

This allows consumer to override in a cleaner way while still prevent
them from hitting bug without knowing they run an unsupported
configuration.

Recommit after fix by Christopher Tetreault to add parens and ${} to
cmake check to work around CMake configure time "unknown arguments
specified" issue

Differential Revision: https://reviews.llvm.org/D73677
Differential Revision: https://reviews.llvm.org/D73751

(cherry picked from commit 5f94022)

Summary:
For -fpatchable-function-entry=N,0 -mbranch-protection=bti, after
9a24488, we place the NOP sled after
the initial BTI.

```
.Lfunc_begin0:
bti c
nop
nop

.section __patchable_function_entries,"awo",@progbits,f,unique,0
.p2align 3
.xword .Lfunc_begin0
```

This patch adds a label after the initial BTI and changes the __patchable_function_entries entry to reference the label:

```
.Lfunc_begin0:
bti c
.Lpatch0:
nop
nop

.section __patchable_function_entries,"awo",@progbits,f,unique,0
.p2align 3
.xword .Lpatch0
```

This placement is compatible with the resolution in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424 .

A local linkage function whose address is not taken does not need a BTI.
Placing the patch label after BTI has the advantage that code does not
need to differentiate whether the function has an initial BTI.

Reviewers: mrutland, nickdesaulniers, nsz, ostannard

Subscribers: kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D73680

(cherry picked from commit 06b8e32)

Summary:
Preserve the old ABI for __cxa_exception and __cxa_dependent_exception
on 64 bit platforms or ARM_EHABI platforms.

After r276215, libunwind in llvm-project labels _Unwind_Exception to be
double word aligned. That change implictly adds a padding before
unwindHeader field in __cxa_exception and __cxa_dependent_exception.
Preserve the same negative offsets in those struct by moving the padding
to the beginning of the field.

The assumption here is that if the ABI is not aware of the padding before
unwindHeader and put the referenceCount/primaryException in there, no padding
should exist before unwindHeader.

Reviewers: EricWF, mclow.lists, ldionne, jroelofs, dexonsmith, rjmccall, compnerd, phosek, ahatanak

Reviewed By: rjmccall

Subscribers: hans, smeenai, kristof.beyls, christof, jkorous, ributzka, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D72543

(cherry picked from commit f2a4360)

…nt along with function parameters

We previously instantiated type-constraints of template type parameters along with the type parameter itself,
this caused problems when the type-constraints created by abbreviated templates refreneced other parameters
in the abbreviated templates.

When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of
the type-constraint until the function parameter which created the invented template type parameter is
instantiated.

(cherry picked from commit eacca48)

…constraint along with function parameters"

This temporarily reverts commit 2b54b8b which caused some test failures.

…nt along with function parameters

We previously instantiated type-constraints of template type parameters along with the type parameter itself,
this caused problems when the type-constraints created by abbreviated templates refreneced other parameters
in the abbreviated templates.

When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of
the type-constraint until the function parameter which created the invented template type parameter is
instantiated.

Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint
a second time.

(cherry picked from commit 84959ae)

Pipeline scheduler model for the RISC-V Rocket micro-architecture using the
MIScheduler interface.  Support for both 32 and 64-bit Rocket cores is
implemented.

Differential revision: https://reviews.llvm.org/D68685

(cherry picked from commit 838a28e)

This reverts commit 0dc6c24.

The commit is reported to cause a regression in piglit/bin/glsl-vs-loop for
Mesa.

(cherry picked from commit a80291c)

The recommended optimization level for BPF programs
is O2 since (1). BPF is running inside the kernel and
linux kernel won't work at -O0 level, and (2). Verifier
is not able to handle O0 code properly, e.g., potential
large stack size and a lot of spills.

But we should keep -O0 at least compiling.
This patch fixed a bug in BPFMISimplifyPatchable phase
where with -O0, a segmentation fault will happen for a
simple program like:
  int test(int a, int b) { return a + b; }

A test case is added to capture such a case.

Differential Revision: https://reviews.llvm.org/D73681

(cherry picked from commit 795bbb3)

R600 relies on this behaviour.
Fixes: 6e18266 ('Partially revert D61491 "AMDGPU: Be explicit about whether the high-word in SI_PC_ADD_REL_OFFSET is 0"')
Fixes ~100 piglit regressions since 6e18266

Differential Revision: https://reviews.llvm.org/D72991

(cherry picked from commit 1b8eab1)

(cherry picked from commit 7dc49f7)

Summary: Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44745 | readability-else-after-return crashes ]]

Reviewers: aaron.ballman, alexfh, hokein, JonasToth, gribozavr2

Reviewed By: alexfh

Subscribers: merge_guards_bot, xazax.hun, cfe-commits

Tags: #clang, #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D73841

(cherry picked from commit d591bdc)

Otherwise Visual Studio 2017 will complain about
llvm::StringRef::strlen not being constexpr:

  StringRef.h(80): error C3615: constexpr function 'llvm::StringRef::strLen' cannot result in a constant expression
  StringRef.h(84): note: failure was caused by call of undefined function or one not declared 'constexpr'

(cherry picked from commit b3d7d10)

…2019

The fix in b3d7d10 compiled nicely,
but didn't link because at least the VS 2017 version I use doesn't
have the builtin yet. Instead, make use of the builtin with MSVC
conditional on VS 2019 or later.

(cherry picked from commit ff837aa)

Win64 isn't LP64, it's LLP64, but there's no __LLP64__ predefined -
just check _WIN64 in addition to __LP64__.

This fixes compilation after static asserts about the struct layout
were added in f2a4360.

Differential Revision: https://reviews.llvm.org/D73838

(cherry picked from commit 09dc884)

ThunkSection contains 4-byte instructions on all targets that use
thunks. Thunks should not be used in any performance sensitive places,
and locality/cache line/instruction fetching arguments should not apply.

We use 16 bytes as preferred function alignments for modern PowerPC cores.
In any case, 8 is not optimal.

Differential Revision: https://reviews.llvm.org/D72819

(cherry picked from commit 870094d)

There's an ABI breakage here if LLVM is compiled in C++14 without
aligned allocation and a user tries to use the result with aligned
allocation. If DenseMap or unique_function is used across that ABI
boundary it will break (PR45413). Moving it out of line is a bit of
a band-aid and LLVM doesn't really give ABI guarantees at this level,
but given the number of complaints I've received over this it still
seems worth fixing.

The exact warning was:
include/clang/AST/DeclarationName.h:210:52: error: arithmetic between different enumeration types ('clang::DeclarationName::StoredNameKind' and 'clang::detail::DeclarationNameExtra::ExtraKind') is deprecated [-Werror,-Wdeprecated-enum-enum-conversion]

`getHasRegParm()` was working under the assumption that the RegParm
bits are the last field, which is no longer true, after adding the
`NoCfCheck` field.

This causes a spurious "regparm 0" attribute to appear when a function
type is declared with `__attribute__((nocf_check))`.

Differential Revision: https://reviews.llvm.org/D77270

clang was complaing about this code:
llvm/include/llvm/IR/PassManager.h:715:17: error: ISO C++20 considers use of overloaded operator '!=' to be ambiguous despite there being a unique best viable function with non-reversed arguments [-Werror,-Wambiguous-reversed-operator]
      if (IMapI != IsResultInvalidated.end())
          ~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~
llvm/include/llvm/ADT/DenseMap.h:1253:8: note: candidate function with non-reversed arguments
  bool operator!=(const ConstIterator &RHS) const {
       ^
llvm/include/llvm/ADT/DenseMap.h:1246:8: note: ambiguous candidate function with reversed arguments
  bool operator==(const ConstIterator &RHS) const {
       ^

The warning is triggered when the DenseMapIterator (lhs) is not const and so
the == operator is applied to different types on lhs/rhs.
Using a template allows the function to be available for both const/non-const
iterator types and gets rid of the warning

Part of the <=> changes in C++20 make certain patterns of writing equality
operators ambiguous with themselves (sorry!).
This patch goes through and adjusts all the comparison operators such that
they should work in both C++17 and C++20 modes. It also makes two other small
C++20-specific changes (adding a constructor to a type that cases to be an
aggregate, and adding casts from u8 literals which no longer have type
const char*).

There were four categories of errors that this review fixes.
Here are canonical examples of them, ordered from most to least common:

// 1) Missing const
namespace missing_const {
    struct A {
    #ifndef FIXED
        bool operator==(A const&);
    #else
        bool operator==(A const&) const;
    #endif
    };

    bool a = A{} == A{}; // error
}

// 2) Type mismatch on CRTP
namespace crtp_mismatch {
    template <typename Derived>
    struct Base {
    #ifndef FIXED
        bool operator==(Derived const&) const;
    #else
        // in one case changed to taking Base const&
        friend bool operator==(Derived const&, Derived const&);
    #endif
    };

    struct D : Base<D> { };

    bool b = D{} == D{}; // error
}

// 3) iterator/const_iterator with only mixed comparison
namespace iter_const_iter {
    template <bool Const>
    struct iterator {
        using const_iterator = iterator<true>;

        iterator();

        template <bool B, std::enable_if_t<(Const && !B), int> = 0>
        iterator(iterator<B> const&);

    #ifndef FIXED
        bool operator==(const_iterator const&) const;
    #else
        friend bool operator==(iterator const&, iterator const&);
    #endif
    };

    bool c = iterator<false>{} == iterator<false>{} // error
          || iterator<false>{} == iterator<true>{}
          || iterator<true>{} == iterator<false>{}
          || iterator<true>{} == iterator<true>{};
}

// 4) Same-type comparison but only have mixed-type operator
namespace ambiguous_choice {
    enum Color { Red };

    struct C {
        C();
        C(Color);
        operator Color() const;
        bool operator==(Color) const;
        friend bool operator==(C, C);
    };

    bool c = C{} == C{}; // error
    bool d = C{} == Red;
}

Differential revision: https://reviews.llvm.org/D78938